Onboarded Model Experiments service on Stackit CLI - #1587

Is there a specific reason why command is named as "ai-model-experiments"? I would prefer here we call it "model-experiments", as we onboarded terraform resources also like that. We can mention in descriptions, in short long fields as AI Model Experiment.

https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs/resources/modelexperiments_instance

I saw that in Portal it is called AI Model Experiment and we generally align with them, but then we will differ from SDK and Terraform Provider.

we can onboard the newer version v0.3.1

We should add it also here the endpoint key

If It is renamed to ModelExperiments, please adapt the suggestion

You can combine this check with the above one, like you have done in the GetTokenName function.

This is a const and can be defined as

const (
testRegion = "eu01"
)

getInstanceFails would be more understandable.

This is also valid for the following vars

getInstanceResp
getTokenFails
getTokenResp

as I already commented in the instance.go, command must be called "describe"

For clarity, Please add here one more example which is using the output flag

nitpick: function can be called buildRequest

This might be a nitpick, but I think it will help a lot for the readability and uniformity across the cli. Please use the same indentations and single/multi line styling in return and function headers

In the describe command output, we create table differently than the list command output. Please take a look at the other describe command output functions for example.

Besides that, in describe command we expect a more detailed output for the user. In the table view, you can also provide the same information shown in the json or yaml outputs.

nitpick: you can use this directly as globalflags.ProjectIdFlag

Region value has been used across the tests. Here you can define a const and use that one.

const testRegion = "eu01"

Here you can define a fixtureArgValues function and use this in the following tests argValues fields. In case you need to make a change, it will be simpler.

as I mentioned above, if you define a const, you can use it in here

why do you use pointer here *map[string]string?

Please add more unit tests here. You can see in other describe commands some example test cases you can add

some examples

	{
		description: "no values",
		argValues:   []string{},
		flagValues:  map[string]string{},
		isValid:     false,
	},
	{
		description: "no arg values",
		argValues:   []string{},
		flagValues:  fixtureFlagValues(),
		isValid:     false,
	},
	{
		description: "no flag values",
		argValues:   fixtureArgValues(),
		flagValues:  map[string]string{},
		isValid:     false,
	},

for following the similar coding style to the existing tests

You can give here multiple examples. One simple one without mentioning region flag. Region is a global flag, you dont really need to mention. But if you want to mention in your example, maybe give it in separate example and by mentioning .... in a project in region eu02 e.g

BEsides that one example with the output format would be nice. You can see examples in other list commands

the comments I left in other scripts about function headers are valid across whole PR. :)

In list commands, we use the limit flag to set the max number of entries to list. Please extend this. Examples can be found in other list commands

I think mentioning the project name would be a nicer output. You need to parse the projectLabel to outputResult function call.

Portal shows in list view bucket name as "ARTIFACT STORAGE NAME", we can also add into here.

The dashboard link, might be skipped in my opinion.

Please see comments from the describe (get) command, about the var grouping, const region, pointer usage etc.

Also here tests can be extended

We can define multiple labels as key=value pairs and seperating with ,'s . So it would make sense to call this as labelsFlag = "labels"